Questions
23 of 24
1How does NestJS resolve constructor injection at runtime?
2What does @Optional() decorator do in NestJS?
3What is the difference between moduleRef.get() and moduleRef.resolve() in NestJS?
4When do you need @Inject(TOKEN) vs plain constructor injection in NestJS?
5What is ModuleRef in NestJS and when would you use it?
6What are the three provider scopes in NestJS and when is each appropriate?
7What is the correct architectural solution for circular dependencies beyond forwardRef()?
8How do you detect and debug circular dependency errors in large NestJS projects?
9What is property-based injection in NestJS and when should you use it?
10How do you write a unit test for a NestJS service that has injected dependencies?
11What is a DI token and what types can be used as tokens in NestJS?
12How do you pass a custom REQUEST object to a REQUEST-scoped provider for queues or CRON jobs in NestJS?
13How does forwardRef() solve circular dependencies in NestJS and how does it work internally?
14How do you implement the Strategy pattern using NestJS DI?
15How do you replace a provider in a NestJS test module using overrideProvider()?
16What is Inversion of Control (IoC) and how does NestJS implement it?
17What is the difference between Dependency Injection (DI) and Inversion of Control (IoC)?
18What is scope propagation in NestJS and why can it impact performance?
19How do you inject the raw HTTP request object inside a REQUEST-scoped provider in NestJS?
20How does moduleRef.resolve() work with scoped providers and what is ContextIdFactory used for?
21What role does reflect-metadata play in NestJS DI?
22What is a circular dependency in NestJS and how does it manifest at runtime?
23What is LazyModuleLoader in NestJS and how does it differ from standard DI?
24What happens to REQUEST-scoped providers during WebSocket connections or microservice message handling in NestJS?
23 / 24

What is LazyModuleLoader in NestJS and how does it differ from standard DI?

Standard DI resolves all providers at bootstrap time. LazyModuleLoader defers a module's initialization until its providers are first accessed at runtime. After the first load the module is cached. It is useful for heavy optional modules like PDF generation or image processing that are rarely invoked.

Lazy loading a module on demand
Differences from standard DI:
  1. 1

    Standard DI — all providers instantiated at app startup; module graph fully resolved before app accepts requests.

  2. 2

    LazyModuleLoader — module initialized on first access; reduces startup time and memory for rarely-used features.

  3. 3

    Lazy modules are cached after first load — subsequent calls use the same module instance.

  4. 4

    Controllers cannot be lazy-loaded — only service-level providers in the lazy module.

  5. 5

    Best for: report generation, image processing, export features, admin-only operations.